Credit Card payments

1 Introduction[//]

The system supports credit card payments. This functionality is dependant on individual credit card ‘brokers’. This document describes some general procedures as well as those specific to BucksNet.

Licence information

Note that Credit Card payments are not a standard part of the Vubis Smart application. It requires a specific license and must be installed and activated separately. Please contact your account manager for pricing and installation information.

In the documentation below, we use the term “credit card” but this also includes debit cards (or any other mechanism supported by BucksNet).

When a borrower wishes to pay by credit card, the system identifies the total amounts owing, and simply passes this information to a secure Internet URL managed by Bucks Net Service Ltd. A unique URL is maintained for each library by BucksNet which corresponds to a web page with a look and feel configured to match the library’s policies.

Clicking on the “Credit/Debit card payment” command icon (from within the online or

WebOpac), offers a screen that might look something like :

Once a borrower’s card details have been entered, then these are validated, checked and the results – success or failure – are returned by Bucks Net to Vubis Smart. The relevant charges are marked as paid, if successful.

2 Setup for Bucks Net [//]

Two online forms are required –one for use from the WebOpac, the other for use from the main online system i.e. for staff use. These contain the fields shown above, as dictated by Bucks Net for input but there are probably some minor changes in layout for Web versus online use.

The setting up of these is handled in liaison with Bucks Net.

In addition, if multilingual input forms are required, then separate forms may be required for each language. An optional setting allows a language code, according to the current on-screen language, to be passed to BucksNet, such that a different “skin” is put on the screen’s displayed by Bucks net.

There is an additional charge for setting up each Web input form, so one alternative is to define multi lingual wording on a single form i.e. instead of two forms, one of which asks for “Card number” and the other for “Numero de carte”, it might be easier to offer a single prompt “Card number/Numero de carte”.

3. Setup Parameters on Vubis Smart [//]

See the help on AFO 497 for more information on these parameters.

Allowing Payments from the WebOpac

An additional option in the User Activities setup in the WebOpac preferences allows the ability to pay by credit card to be turned on or off by Web “profile”.

4. Deciding on which URL to use [//]

Within the system, the charges shown at any one time are for the borrower as a whole i.e. for the circulation meta-institution. However, in principle, the borrower may have overdue fines (for example) from actual institutions A and B. In this case, separate payments must be made for each organisation – it is NOT the location from which the payment is initiated that is important . It is the location of the transaction which determines the server page to be accessed on BucksNet.

The precise rules and parameters for this are defined in the Payments By Location specification.

4.1 Online System Payments[//]

For staff initiated payments, the system aggregates the outstanding charges for each financial group. If there is more than one group associated, then a grid is shown

For example,

Nr	Organisation	Amount	Note
1.	CamfordShire Libraries	12.50
2.	CamfordShire Schools Library Service	4.25	CC payment not allowed
3.	No credit card payment available	5.25

In this case, whilst a total of 22.00 is owed, 5.25 of this is associated with locations for which credit card facilities have not been assigned (line 3) and 4.25 is too small to be payable by credit card.

The “organisation” field is determined from the financial grouping used to aggregate the charge, via the table defined in section “Charges By Location” of the Charge By Location specification.

From this grid, specific valid lines may be chosen to initiate the payment.

If there is no ambiguity about the organisation concerned, then the accept credit card payment details screen is opened automatically.

A system wide option allows this rather complicated grid to be suppressed. In this case, the financial group associated with the patron’s home location is used as the organisation to whom the payment will be made (see the section on Credit card payment limits and options).

4.2 WebOpac Payments[//]

From the WebOpac, the subtleties of the previous section are too convoluted to explain or share with the borrower. In this case, if there are possible multiple destinations for the payments, then the payment URL associated with the patron’s home location is used for ALL charges (and if no URL can be associated with the home location, then credit card payment will be disallowed).

Credit card payment may be initiated from the “User Activities / My account” screen - an example of which is shown above. An additional “Credit Card payments” button will be displayed if the Credit Card Payment Limits / In Use setting is “on”.

Clicking on the payments button may result in one of the following – the opening of the BucksNet URL (as determined by the rules in the previous section), or an error condition which may be one of

· The amount owing is too small to be paid by credit or debit card

· It is currently not possible to use credit card payments (if no URL could be determined)

· Please note that an additional charge of xx.xx will be charged for credit card payments. – followed by an additional option to accept or back out of the transaction.

Similar functionality will be available on the Deposits screen.

4.3 Payment from Online System[//]

The option to pay by credit card is offered from AFO414/431 – Accept payment screen. An additional “credit card” icon may be offered.

The credit card option is only active if the total amount payable is greater than the minimum amount setting, configured according to Credit card payment limits (although it should be noted that in unusual circumstances credit card payments may still not be possible).

The system will then ask who is actually going to make the payment. Suppose, for example, that a borrower returns several overdue items on behalf of their family. In this case, the Accept payments screen may show several items borrowed by several different borrowers. Since it is necessary to pass some details across to BucksNet, so that an appropriate receipt may be printed, for example, the following form is displayed.

By default, the barcode of the first borrower on the accept payments screen is used, but any other borrower’s barcode may be entered (and is validated). However, it is of course possible that the credit card holder is not even registered with the library. In this case, you may enter a name and email address manually into the fields in the bottom section. (Entering data into these field overrides any checking of the “barcode” field).

It is possible to cancel the payment operation at this point.

Once accepted (if appropriate) a Web page is opened with the address defined for the location of the charges.

It should be noted that any additional charge made for a card payment is displayed at the bottom of this screen.

4.3.1 Online Displays during payment processing[//]

During this process, the outstanding charges are marked as “provisionally paid”. Since a separate browser window is opened, it is feasible that the borrower data is accessed separately by other online or WebOpac sessions.

In this case, all payment options are “frozen” and a message is displayed for each borrower shown on the Accept payments screen and also in the “Open amounts summary” screen in the WebOpac.

This may also occur if, for example, the processing against BucksNet was interrupted, for example by an Internet problem etc. Because of the security implications, this can only be “untangled” by a separate function – see the section on Reparing transactions.

4.4 Successful payment[//]

The success of a payment is returned by BuckNet opening a VubisSmart Webpage.

The Webpage address is configured in the WebOpac and is the same for both staff and WebOpac functions.

The Webpage carries out two functions – firstly an acknowledgement by VubisSmart. The wording may be defined by the library- but would something to the effect that

Your online payment has been successfully processed.

with a “Close window” button to close the window.

In addition, the Web page processing marks all the relevant transactions as fully paid.

4.5 Failure[//]

A failure Web page may also be opened by BucksNet to indicate that there was a problem.

In this case, a browser screen is opened to indicate failure. A reason for the failure is returned by BucksNet and will be displayed in the screen.

The marking of payments as provisionally paid is “undone” by the system.

5. Borrower’s financial and transaction history[//]

A unique transaction id is allocated to any credit card payment. The “Borrower’s financial history” list (and details screen) as shown below is updated to display this unique reference number.

Here is a sample output for a borrower

Note that there are five types of transaction :

· Credit card payment indicates that this user has started to make a credit card payment. As pointed out above – it should be noted that this is logged against the card holder (if registered with the library)

· Credit card pay submitted indicates that the processing against BucksNet started

· Credit card pay accepted indicates that the payment completed OK.

· Credit card pay failed indicates that the payment failed

· CardHolder payment failed logged against the cardholder.

If the payment was rejected (e.g. a bad credit card), then

is logged against the borrower for whom the charge is being paid. So there should always be

Credit card pay submitted, followed by

Credit card pay accepted OR

Credit card pay failed

Finally,

may also be logged against the card holder’s transaction history. CardHolder payment successful is NOT logged.

Succesful payments are also logged in the borrower’s payment history list – for example,

The card pay submitted, accepted and failed transactions are , logged against each borrower for whom the charges are made. In the above example, the borrower is paying for their OWN charges. “Credit card payment” and “CardHolder payment failed” are logged against the actual borrower (if they are registered) who is paying.

6. Payment of money into a deposit by credit card[//]

Payment into a deposit by credit card is possible by selecting the “credit/debit card” payment method, assuming that this has been setup as a valid payment type for deposit.

In this case, it is not possible to add money into a deposit fund without the user actually paying for it. The user cannot “owe” the amount to be paid in. The workflow is slightly different therefore for such payments.

In this case, the system proceeds as for a regular credit card payment (asking for the details of the cardholder, and then connecting to BucksNet for the actual payment to go through).

On the client side (normally invisible to the staff user, since a Web Browser session will be in progress), the system is put into a “wait” state – waiting for the success or failure of the card transaction.

Once the transaction is completed, then the system will accept the credit card payment, or it will have been rejected. However in the event of a problem, pressing the Cancel command button will cause the following window to pop-up.

The system will assume that the payment was unsuccessful, but in fact it cannot know. The card holder may or may not have been debited with the amount requested.